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The National Airspace System (NAS) must be improved to increase capacity, reduce flight 
delays, and minimize environmental impacts of air travel. NASA has been tasked with aiding 
the Federal Aviation Administration (FA A) in NAS modernization. Automatic Dependent 
Surveillance-Broadcast (ADS-B) is an enabling technology that is fundamental to realization of 
the Next Generation Air Transportation System (NextGen). Despite the 2020 FAA mandate 
requiring ADS-B Out equipage, airspace users are lacking incentives to equip with the 
requisite ADS-B avionics. A need exists to validate in flight tests advanced concepts of 
operation (ConOps) that rely on ADS-B and other data links without requiring costly equipage. 
A potential solution is presented in this paper. It is possible to emulate future data link 
capabilities using the existing in-flight Internet and reduced-cost test equipment. To establish 
proof-of-concept, a high-fidelity traffic operations simulation was modified to include a module 
that simulated Internet transmission of ADS-B messages. An advanced NASA ConOp, Flight 
Deck Interval Management (FIM), was used to evaluate technical feasibility. A preliminary 
assessment of the effects of latency and dropout rate on FIM was performed. Flight hardware 
that would be used by proposed test environment was connected to the simulation so that data 
transfer from aircraft systems to test equipment could be verified. The results indicate that the 
FIM ConOp, and therefore, many other advanced ConOps with equal or lesser response 
characteristics and data requirements, can be evaluated in flight using the proposed concept. 
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I. Introduction 

T HE Next Generation Air Transportation System (NextGen) is a suite of solutions aimed at improving the National 
Airspace System (NAS) by increasing system capacity, reducing flight delays, and minimizing environmental 
impacts of air transportation. [1] Automatic Dependent Surveillance-Broadcast (ADS-B) is a technology that is 
fundamental to the realization of the NextGen concept. ADS-B consists of two different services. ADS-B Out enables 
aircraft to broadcast state information such as identity, position, and speed. Such broadcasts can be received by Federal 
Aviation Administration (FAA) ground stations as well as aircraft equipped with ADS-B In. Anticipated benefits of 
ADS-B In include increased situational awareness and opportunities to utilize advanced Concepts of Operation 
(ConOps) aimed at increasing the efficiency of the NAS. The FAA has mandated ADS-B Out equipage for the 
majority of aircraft that operate within the NAS by 2020. [2] 

An aircraft equipped with ADS-B Out can broadcast its position obtained from on-board GPS at an accuracy and 
refresh rate that greatly exceeds that of radar. This will drastically reduce the cost of maintaining the ground-based air- 
traffic management infrastructure. ADS-B utilization of GPS position broadcasting will also improve the overall 
quality of information used to manage air traffic and virtually eliminate coverage gaps that currently exist with radar. 
However, airspace users are concerned because the cost of installing ADS-B Out equipment does not provide enough 
direct user benefit to justify their capital investments. For airspace users, the full benefit provided by ADS-B 
materializes when using ADS-B In, and only after a substantial portion of aircraft are equipped with ADS-B Out. 

The National Aeronautics and Space Administration (NASA) and others have been conducting research of advanced 
NextGen ConOps that are dependent on data links such as ADS-B In and Out and Controller-Pilot Data Fink 
Communications (CPDFC). Unlike many of the ADS-B Out-only ConOps, these advanced ConOps are anticipated to 
provide direct user benefits as well as system benefits. To date, the majority of research and development for these 
ConOps has almost exclusively been conducted using modeling, analysis, and Human -in-the-Foop (HITF) simulation. 
To continue progress toward implementation of these advanced ConOps as future elements of the NAS, extensive 
validation and refinement must occur in the environments of their ultimate use. 

Of the advanced data links, there is widespread interest in transformational potential of ADS-B surveillance. There is 
currently no mandate for the installation of ADS-B In, and there are several barriers hindering voluntary equipage. In 
addition to the lack of a business case due to the asymmetric benefit during the transition to full ADS-B adoption, 
ADS-B standards are still maturing and users face the possibility of investments in equipment becoming obsolete 
before there are positive investment returns. Furthering the research of these advanced ConOps to an in situ test phase 
would likely involve the use of commercial-of-the-shelf ADS-B equipment. Most air traffic management (ATM) 
ConOps involve many aircraft, which makes in-flight evaluation of the concepts very costly. This creates a challenge: 
airspace users are reluctant to invest in equipage due to the high cost and a lack of direct benefits, and research 
validating and demonstrating the benefits cannot materialize until the users are equipped. 

As an alternative, it is proposed to make use of in-flight Internet, a commercially available two-way data link, to 
connect simulations of ADS-B broadcasts and receptions on each participating aircraft. Referred to as the Networked 
Air Traffic Infrastructure Validation Environment (NATIVE), this flight test capability may be able to accelerate the 
transition to widespread implementation of ADS-B and other advanced data links by providing affordable and timely 
validation of ConOps that rely on them. NATIVE may also be able to accelerate the maturation of standards for these 
data links by validating the need of proposed new message content to support specific advanced ConOps. If realized, 
the NATIVE concept would involve real-time data link simulations utilizing in-flight Internet for message exchange 
between participating aircraft and ground systems. Electronic Flight Bags (EFBs) or laptops would be temporarily 
mounted in the cockpits of participating aircraft. The EFBs would host the ADS-B simulation, the advanced 
applications that support the tested ConOp, and if necessary, provide a display for emulated ADS-B information. 
Ground-based computer systems would receive emulated ADS-B information and assemble the full traffic picture for 
up-link to each aircraft. 

To determine feasibility and viability of the NATIVE approach to flight validation, two parallel studies were 
performed. One study investigated feasibility by determining system requirements and investigating the availability of 
existing technologies to meet them. [3] The study also performed an initial cost-benefit assessment. This paper 
describes the second study, which sought to establish proof-of-concept through simulation and analysis of a potential 
NATIVE use. The primary technical feasibility issues with the NATIVE concept are related to the behavior of the 
Internet and the sending of information from the aircraft avionics bus to the EFB for use in the application that supports 
the advanced ConOp. Because many advanced ConOps involve flight guidance, effects of round-trip data exchange 
delays and drop-outs were deemed to be of concern. A NASA ConOp which involves providing active speed guidance 
to flight crews was selected because some design configurations require very high data link capabilities relative to 
other ConOps. Internet characteristics were modeled and added to an advanced NASA ATM simulation, and a series of 
tests were conducted to evaluate the effect of the Internet data link. The study also sought to verify that information 
necessary for the implementation of the ConOp could be transferred from the hosting aircraft to candidate NATIVE 
flight hardware. 
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II. An Example Application of NATIVE 

To illustrate the application of the NATIVE concept, its hypothetical use in a flight test arena is described for an 
advanced ConOp that is designed to increase runway throughput for arrival operations in capacity-constrained terminal 
environments. The integrated air/ground ConOp combines advanced arrival scheduling, airborne precision spacing, 
and controller-managed spacing to achieve high arrival throughput while enabling fuel-efficient optimal descent 
profiles. All aircraft are assigned to Standard Terminal Arrival Routes that are continuous to the Final Approach Fix 
(FAF). During descent, aircraft equipped with ADS-B for traffic surveillance will manage their individual speeds to 
achieve precise spacing intervals at the FAF. This airborne element of the integrated ConOp is referred to as Flight 
Deck Interval Management (FIM), and makes use of an airborne spacing control algorithm known as Airborne Spacing 
for Terminal Arrival Routes (ASTAR). Pair-Dependent Speed (PDS) guidance is provided to each flight crew. This 
guidance assigns a lead aircraft and interval, which can be time or distance -based, and provides a continuously- 
updating commanded airspeed required by the ownship to achieve the precise spacing. The arrival sequence and the 
FAF spacing intervals are assigned by the ground-based scheduling technology, known as Traffic Management 
Advisor with Terminal Metering (TMA-TM). Controllers manage unequipped aircraft using technology known as 
Controller Managed Spacing (CMS). TMA-TM and CMS make up the ground-based ConOp element. The integrated 
air/ground ConOp is described in detail in Ref. [4] 



Figure 1. NATIVE application to an advanced ADS-B ConOp. 

In a flight test configuration that utilizes NATIVE, aircraft equipped with in-flight Internet services may participate 
without ADS-B Out or In equipment. As shown in Figure 1, the Internet provides a communications backbone for an 
ADS-B simulation. An EFB or laptop is temporarily installed as test equipment on each participating aircraft. Using an 
industry-standard data concentrator, real time information from each aircraft is obtained from its avionics systems and 
provided to the test equipment. The aircraft state information is used to support the airborne guidance and to construct 
an ADS-B broadcast message. The test equipment constructs the simulated ADS-B Out message and sends it through 
the Internet down-link to a ground-based component of the NATIVE system. The ground-based component receives 
simulated ADS-B or real broadcast messages from all participating aircraft and assembles a continuously-updated 
traffic data base. This component can also accept traffic information from existing FAA traffic automation systems, 
such as the En Route Automation Modernization (ERAM) system, and from traffic simulators that generate virtual 
traffic. If necessary, the ground-based NATIVE component can provide traffic information to the advanced scheduling 
and sequencing automation technology. All traffic data from the NATIVE ground system are passed through Internet 
up-links to the on-board test equipment of each participating aircraft. Airborne test equipment Internet access is 
provided either through a direct TCP/IP connection or a wireless connection. The existing NASA ADS-B reception 
simulation resides within the on-board test equipment. It filters out any traffic information that an actual ADS-B unit 
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would not have been able to detect, thereby creating a set of simulated ADS-B In messages for each aircraft. The 
airborne technology hosted by the test equipment then uses the simulated ADS-B In information and the directly 
received ownship information to provide speed guidance to the pilot. Other advanced two-way data links that may be 
needed by the ConOp, such as future instantiations of Controller/Pilot Data Link Communications (CPDLC), may also 
be simulated using the NATIVE concept. 

III. Technical Feasibility Issues 

Three technical areas were identified as posing risk to the NATIVE concept: adequacy of in-flight Internet 
performance to support ADS-B simulation, algorithm sensitivity to varying performance of the simulated ADS-B, and 
integration of NATIVE test equipage with the test aircraft’s existing avionics infrastructure. Because of the 
dependency of the proposed system on in-flight Internet capabilities, anticipated in-flight Internet issues were related to 
bandwidth throughput, round-trip latency, variability of latency, and dropouts. Bandwidth requirements were 
investigated by McCormack, et al. and found not to be a limiting issue. [3] However, data transmission delays and 
intermittent connectivity were of concern. Independent of the system implementation, in-flight Internet is targeted 
primarily to passenger entertainment and comfort and is not designed to provide critical data delivery. There are 
several factors such as the overhead of managing bandwidth, system-to-aircraft transmission infrastructure and varying 
load imposed on the communication link by passengers that create uncertainty as to the actual, in-cabin performance of 
the system. The uncertainty is exacerbated when considering that ADS-B simulation utilizes communication patterns 
that are different from typical consumer-based patterns. For example, ADS-B simulation requires periodic bi- 
directional communication that uses relatively low bandwidth but assumes data delivery delays similar to the direct 
broadcast technology employed in actual ADS-B. Most consumer-generated Internet traffic is heavily biased towards 
downloading as opposed to uploading data and for the majority of uses (email, media streaming) round trip time is not 
as important as bandwidth. Cumulatively, these issues created a lot of uncertainty regarding the feasibility of using in- 
flight Internet as a NATIVE communications backbone. 

Provided that in-flight Internet offers adequate performance for ADS-B simulation, a second but equally important 
concern was the sensitivity of both distributed and centralized traffic management algorithms to communication 
performance that could be significantly different from real ADS-B. To the best of the researchers’ knowledge, the 
effect of stale data on traffic management algorithms has not been extensively studied, but it is well known that any 
system that utilizes feedback can be highly sensitive to delays. In the case of in-flight Internet, data transport delays 
and delays caused by re-transmissions due to lost data will introduce varying levels of feedback lag and studying such 
effects is critical. 

A final issue of concern was the feasibility of properly integrating Internet -produced data and ownship aircraft data 
with any on-board equipment required for a given NATIVE test. Technically and logistically, such integration should 
be done in a way that minimizes, or even eliminates, any required changes beyond the substitution of the on-board 
portion of the NATIVE system in place of flight system hardware (i.e., the traffic computer, defined by ARINC 
Characteristic 735B). From a technical standpoint, such integration must provide all data necessary to the ConOp’s 
airborne algorithms and applications hosted by the test system. Many EFBs allow for direct TCP/IP connectivity, 
thereby enabling a connection to the in-flight Internet system. Access to internet data is therefore a matter of approval. 
However, access to ownship data requires a feed of real-time data from one or more the aircraft’s data buses. NATIVE 
has a goal of being applicable to any advanced concept for which all needed data are available from standard data 
buses. On the concept practicality front, developing a system that cannot easily be integrated into an actual cockpit 
would diminish the value of NATIVE. Ideally, no aircraft modifications should be required beyond a connection to a 
Class 2 EFB or its equivalent. 


IV. Approach 

To resolve these feasibility issues, a candidate ATM ConOp was modeled and simulated as it would be configured 
for a NATIVE flight test. An existing high-fidelity traffic simulation that includes a model of ADS-B reception was 
used to host the ConOp’s airborne technology. The simulation was augmented with a parametric model of internet 
behavior, which introduced delays and message drop-outs between the broadcast ADS-B messages of target aircraft 
simulations and the receiving aircraft simulation’s ADS-B reception model. The performance of the ConOp was 
evaluated while varying parameters of the internet behavior model. In addition, actual flight hardware, including an 
ARINC 429 data bus, data concentrator, and EFB were connected to the evaluation aircraft simulation to receive the 
aircraft’s state data, as each would be used in a NATIVE instantiation. The received data were evaluated to verify that 
information necessary for the ConOp’s application could be delivered to the test hardware. 

The ConOp selected for the study is FIM, the airborne portion of the integrated air/ground ConOp of Ref. [4] . FIM 
makes use of ADS-B In and Out for direct air-to-air surveillance. [5] [6] The developed proof-of-concept simulation is 
a partial representation of the airborne elements and the Internet data link of Figure 1 . 


4 

American Institute of Aeronautics and Astronautics 



FIM was selected because it uses ADS-B 
surveillance in active speed guidance. FIM speed 
guidance is a closed-loop control application that is 
high bandwidth relative to most air traffic 
management functions. If internet behavior is found to 
have a marginal impact on FIM speed guidance, it is 
reasonable to assume that internet behavior will have 
a marginal impact on the performance of most ATM 
functions. FIM was also selected because 
improvements to the ConOp are envisioned by adding 
additional message content to the current standards. 
This would not be possible if commercial ADS-B 
systems that conform to current standards [7] [8] are 
used. By simulating ADS-B messages, NATIVE 
facilitates the addition of new message content in a 
flight test. Further, FIM is a NATIVE candidate 
because the ASTAR/PDS algorithms and crew 
displays will not be integrated into existing aircraft 
systems in planned near-term implementations. In an 
operational system, they will reside on an EFB and a 
configurable glass display mounted in the primary 
field-of-view. NATIVE test equipment can easily be 
substituted for these hardware components. 

V. Test Equipment and Simulation Capabilities 

NASA’s Airspace and Traffic Operations 
Simulation (ATOS) is a high-fidelity traffic 
simulation designed to enable researchers to develop 
and test vehicle-centric ConOps for NextGen 
implementation. [9] The high fidelity and scalability 
achieved by ATOS results from its architecture, which 
links many individual high-fidelity aircraft 
simulations. [10] To add additional aircraft to the 
simulation, computers are added to the network. 
ATOS is capable of supporting human-in-the-loop 
experiments or batch simulations. [10] 

The primary aircraft simulation within ATOS is 
Aircraft Simulation for Traffic Operations Research 
(ASTOR), which combines a 6-degree-of-freedom 
airframe simulation, flight management and autoflight 
systems, modern glass displays, and a representation 
of an ARINC 429 data bus. ASTOR can be 
implemented on a range of workstations or simulators 
with various levels of fidelity, or it can be run with a 
pilot simulation replacing a human pilot. [9] An image 
of a typical ASTOR workstation is provided in Figure 
2 . 

For the study, two flight simulators complete with 
touchscreen control panels, flight control inceptors, 
and out-the- window views were used. An image of 
one of these flight simulators can be seen in Figure 3. 
Each of the flight simulators provided the platform for 
an ASTOR. One additional ASTOR workstation was 
incorporated for use in the arrival stream. 

If the NATIVE concept is realized, participating 
aircraft will be equipped with EFBs or laptops to act 
as a crew input interface, host the advanced ConOps 
technology, and provide ADS-B emulation. EFBs are 
classified based upon their interaction with aircraft 



Figure 2. ASTOR Workstation. 



Figure 3. Simulators used in the study. 



Figure 4. Electronic flight bag used in test. 
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avionics. [11] Class 2 EFBs may be mounted in the cockpit and can receive data from aircraft systems, but cannot send 
data to the aircraft systems. [12] Class 2 EFBs are therefore adequate to support the NATIVE concept, which for 
certification reasons must not require any modification of any existing aircraft systems. For the study, a Goodrich 
Model 8725 A1 -2 Class 2 EFB was mounted to one of the flight simulators, as shown in Figure 4. A Goodrich Model 
8730G1-1 Aircraft Interface Device (AID) data concentrator provided the link between the EFB and the ASTOR 
simulation. The AID interfaced with a Ballard ARINC 429/717 Interface Board. [13] 

VI. Proof-of- Concept Methodology 


A. Simulation Configuration 



Figure 5. Simulation configuration. 

The simulation configuration used in the study is shown in Figure 5. A lead aircraft was simulated by ASTOR 3. The 
aircraft used for internet evaluation, ASTOR1, was hosted by Simulator 1, and the aircraft used for hardware 
evaluation was ASTOR 2, hosted by Simulator 2. Simulator 2 was directly connected to a computer that hosted the 
Ballard ARINC 429 Interface. This interface was connected to the AID, which was connected to the EFB. 

B. ASTOR configuration 


Simulator 2 Only 



Figure 6. ASTOR configuration for Simulators 1 and 2. 

Figure 6 depicts the integration of the simulation of internet behavior and the EFB flight hardware into the ASTOR. 
To capture the performance characteristics of the Internet, an Internet delay simulation was introduced in front of 
ASTOR’ s ADS-B reception Model. Unfiltered traffic information provided from the other ASTORs via the simulation 
network was input to the Internet delay simulation, which delayed packet delivery and selectively dropped packets to 
simulate a wide range of on-board Internet latency values. The delayed traffic information was then input to the ADS- 
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B In reception simulation. The simulated ADS-B In data are shared with other ASTOR components through the 
AvBus, an ASTOR component that simulates the data layout, timing, and overall performance characteristics of an 
ARINC 429 Bus. The AvBus utilizes labels for each message that are consistent with the ARINC 429 specification. 
This facilitates the integration of simulated avionics in the ASTOR simulation. In the configuration used for the test, 
the PDS/ASTAR guidance and the Navigation Display made use of ADS-B data. In addition, an external interface 
component captured specific message labels from the AvBus and transmitted them through a local area network 
connection to a computer hosting a PCI-based ARINC 429 card made by Ballard Technologies. This transmission 
introduced negligible lag and no data losses. The Ballard ARINC 429 Interface software was running on the host 
computer. Ownship data required to execute the PDS/ASTAR software on the EFB was passed from the Ballard card 
to the AID, and in turn to the EFB. The EFB displayed commanded airspeed required to maintain precision spacing as 
calculated by the PDS/ASTAR algorithm. For the study, the PDS/ASTAR guidance remained within ASTAR. In a 
NATIVE-based flight test, it would be developed to execute in a stand-alone fashion on the EFB. 

C. ADS-B simulation 

ADS-B range is limited to approximately 90 nautical miles. Line-of-sight between broadcasting and receiving aircraft 
must be maintained, and there is a possibility of message interference known as FRUIT (False Replies from 
Unsynchronized Interrogator Transmissions). Therefore, all ADS-B In applications must account for the possibility of 
lost surveillance messages. ASTOR contains an ADS-B reception model that accounts for range and FRUIT, as 
described in Reference [15]. Each ASTOR simulation provides ADS-B out message content to all other ASTORs via 
the ATOS local network. Each ASTOR’ s reception model filters received content from all traffic, allowing messages 
that would be received in the actual environment to pass through. This ADS-B simulation should be applicable to 
NATIVE-based flight tests. 

The maximum allowable uncompensated latency for ADS-B reports is on the order of one second. If the Internet is 
used as a substitute for ADS-B, the messages may occasionally experience greater delays. There is also a possibility of 
messages being received out of sequence in internet transmissions. In actual ADS-B use, a time-of-applicability stamp 
is applied upon message reception. The NASA ADS-B simulation applies a time stamp to each message on broadcast. 
This enables a NATIVE implementation to provide the necessary information to the receiving aircraft to compensate 
for internet transmission artifacts. PDS/ASTAR algorithms used in the study already account for message drop-outs, 
but they do not currently account for the adjustment of message sequence. The algorithms make predictions of current 
target state based on the time stamp associated with the most recent target ADS-B message. 

D. Internet model and simulation 

The Internet model captures two key characteristics of Internet-based message transmission dynamics: delay and 
dropped packets. One can argue that when using reliable protocols (i.e., TCP/IP), dropped packets effectively appear 
as increased delays, but even when using a reliable protocol, practical considerations force the use of time-outs that 
ultimately materialize as dropped messages. Also, delays in message delivery do not entirely depend on network 
infrastructure. Factors that affect the delay include the time it takes a simulated ADS-B message to travel down to a 
ground station, the time it takes the NASA ground-based NATIVE system to incorporate the message into an overall 
traffic picture using information from all other received ADS-B messages, and the time it takes the ground system to 
send the traffic picture back up to all aircraft in involved in the test. Furthermore, messages may be dropped not only 
because of network load but conceivably because excessive load on the ground-based station. The model simulates all 
of these factors by dropping messages based on a probability parameter. Additional model input parameters include 
the mean and standard deviation of the delay for all messages. Both mean and standard deviation were used to capture 
the effects of delay variation in addition to the average value. Special consideration was made to exclude negative 
delays by establishing a minimum delay, independent of the input delay parameters. 

In execution, incoming messages are captured and the dropped message probability is used to determine if the 
message would be lost. A pseudo random number generator with uniform distribution is sampled and the resultant 
value is compared to the message loss probability. If the message is deemed lost, no other action is taken. Messages 
that were not dropped are tagged with a time stamp and assigned a delay value based on a second random number 
generator producing delay values according to the mean and standard deviation input parameters. The message is then 
stored in a buffer. The buffer is continuously scanned for messages whose arrival time plus delay time exceeds the 
current time, at which point such messages are removed from the buffer and delivered to the ADS-B model. 

VII. Test Scenarios and Experiment Design 

The tests investigated the impact of Internet latencies and packet drop-out rate on FIM in a high-fidelity simulation 
environment with a three-aircraft stream comprised of a Boeing 757 in the lead, a Boeing 111 first in trail and equipped 
with NATIVE, and Boeing 737 second in trail and equipped with ADS-B. In these experiments, the three aircraft begin 
at 15, 21, and 26 nautical miles from a runway threshold at Dallas/Fort Worth International Airport, respectively. The 
NATIVE-equipped B777 is designated a 93s time interval behind the lead aircraft, and the B737 is given a 122s 
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interval behind the B777. Each data run was a near-real-time simulation of this scenario. Pilot throttle adjustments to 
follow PDS speed guidance were performed by a pilot simulation. The test scenarios did not include all real-world 
sources of error, so the results shown should not be interpreted as predicted flight test results. 

A full-factorial experiment design was practical for this experiment. The independent variables included mean 
Internet latency, standard deviation of mean Internet latency, and packet drop-out rate. The experiment test matrix is 
presented in Table 1. Ten simulations were performed for each cell, due to the inherent variance within the Internet 
delay model. As well, a larger sample size allowed the researchers to gain statistical power in their results. The lone 
dependent variable is the delivery accuracy, also known as the final interval spacing error. Because the goal of the 
ASTAR algorithm is to maximize throughput and to decrease the distance between aircraft on approach, the final 
spacing interval error was determined to be an appropriate figure of merit with which to measure the performance of 
the ASTAR algorithm. In a perfect case, the final error would approach zero. Delivery accuracy for FIM is considered 
acceptable when 90% of the aircraft in an arrival stream have an absolute value of final interval spacing error less than 
or equal to 5 seconds. 


Table 1: Experiment Test Matrix 


Baseline Test 

- 

Mean Latency (sec) 

0 seconds 

7 seconds 

1 seconds 

10 seconds 

2 seconds 

15 seconds 

3 seconds 

20 seconds 

5 seconds 

25 seconds 

Standard Deviation of Mean Latency (sec) 

0 seconds 

2.5 seconds 

0.5 seconds 

3 seconds 

1 seconds 

3.5 seconds 

1.5 seconds 

4 seconds 

2 seconds 

4.5 seconds 

Drop Out Rate 

0% 

1 % 

0 . 1 % 

2% 


Data were collected from data scripts automatically produced post-simulation by both ASTAR and ATOS. Data were 
post-processed using statistical methods to produce box- whisker style plots. The line within the box represents the 
median value of the population. The box extends from the 25th percentile to the 75th percentile. Outliers are depicted 
as plus signs outside of the box. 


VIII. Results 

Approximately 240 tests were run to obtain the data presented in this section. 


A. Impact of latency 

Examining Figure 7, it is evident that 
the final spacing interval error is not 
drastically affected by the variation in 
the mean latency input to the Internet 
model until a mean latency of 20 
seconds is reached. If tests were carried 
out past 25 seconds, based on the current 
trend of the presented data, a conclusion 
can be made that the algorithm begins to 
malfunction somewhere between 20 and 
25 of seconds of mean Internet latency 
and will completely malfunction 
sometime shortly after 25 seconds. This 
is because the median of the data begins 
to trend away from zero in a drastic 
manner which is not evident before 20 
seconds. This drastic shift in the median 
value indicates that the median 



is 


Figure 7. Mean latency vs. final spacing interval error. 


moving closer to the performance metric upper limit, which signifies failure in the system based on the metric set by 
the researchers. 

Realistically, if during a flight test the Internet proves to be malfunctioning to the point that it exhibits latencies on 
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the order of five seconds, the data 
run would most likely be stopped. 
Anticipated latencies are in the 1-3 
second range based on data 
collected on cross country flight 
tests. [3] This confirms the 
robustness of the ASTAR 
algorithm at high Internet 
latencies, and proves that 
NATIVE can be used for FIM 
operations regardless of latencies 
up to approximately twenty 
seconds. 

After examining Figure 8Error! 
Reference source not found., it is 
clear that the range of the 
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distributions increases as the Figure 8. Standard deviation of mean latency vs. final spacing interval error. 

standard deviation of mean latency 

increases. As well, the variance of the data increases as the standard deviation of mean latency increases. Based on 
these data, the ASTAR algorithm implemented with a NATIVE system can withstand a standard deviation of mean 
latency which is 30% of the mean latency value before it begins performing erratically. This is shown by the closely 
spaced outliers and the closely spaced median values from the baseline trial with a zero standard deviation to the 1.5 
second trial, which has a standard deviation value that is 30% of the mean latency. After that, however, the ASTAR 
algorithm loses precision, which is exposed not only by the number of outliers in the trials above 1.5 seconds, but also 
how large the variance is in each subsequent trial. 


B. Impact of packet dropouts 

Examining Figure 9Figure 9, it 
appears as though dropped packages 
do not have a significant impact upon 
the performance of the ASTAR 
algorithm. A simple conclusion can 
be drawn from the data in this set of 
experiments — there appears to be no 
adverse effect on the ASTAR 
algorithm’s ability to precisely space 
aircraft to the final approach fix. All 
median values of the final spacing 
interval error fall between 0 and 1 
second of absolute error, and no 
outliers are above 2 seconds of 
absolute error. 



C. Lead aircraft final approach speed effects 

Barmore investigated the effects of including the lead aircraft final approach speed in the ASTAR computations. [16] 
By including this information in the calculations, the spacing deviation and variance were minimized. This capability 
requires message content that is not part of current ADS-B standards. The NATIVE system is capable of 
demonstrating advanced concepts which make use of nonstandard message content, such as the FIM concept that uses 
the lead aircraft final approach speed to increase accuracy of the algorithm. 

D. Assessment of technical feasibility 

Analysis results indicate that the currently available in-flight Internet is adequate to simulate ADS-B capabilities in 
flight tests involving the FIM ConOp. Most proposed advanced ConOps that rely on air/air or air/ground data exchange 
have comparable or lower response characteristics and data requirements than FIM, so the NATIVE concept should be 
applicable to these concepts as well. 

Of the three primary concerns, the simulation data address in-flight Internet performance adequacy and algorithm 
sensitivity to varying performance. Without loss of generality, two independent variables were used to capture in-flight 
Internet performance, namely data delivery latency and data packet loss. These variables were varied widely in order to 
identify the performance boundary, and in the case of latency almost to the point of unreasonableness. The data 
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exhibited a trend that the algorithm would fail after 25 seconds of mean latency. That amount of latency is far beyond 
what would be considered a functional connection. Combined with the relatively low bandwidth requirements of ADS - 
B simulation, even under the most challenging performance scenarios and using current technology it is reasonable to 
conclude that ADS-B simulation is feasible. Furthermore, the specific algorithms proved to be very robust in the 
presence of increased latency as well as dropped data, suggesting that the proposed system is feasible, even under 
strained network performance. 

For the third concern, an assessment was made regarding the technical challenges associated with transferring 
ownship data required by the FIM application to potential NATIVE test hardware that would host the application. The 
setup used in this study utilized a data concentrator and an EFB, which are easily installed in modern aircraft. The 
system performed as expected. All information required by PDS from the ownship was successfully passed to the EFB. 
The use of aviation grade equipment proves the feasibility of integrating the same technology into the cockpit without 
requiring any additional equipment and without any adverse effects on the system performance. 

In summary, the NATIVE system was shown to be feasible using current in-flight Internet performance estimates, 
which will likely improve, and using standard Class 2 EFB hardware. These results strongly suggest that NATIVE is a 
viable approach for reduced-cost in- situ validation of NextGen concepts. 

IX. Conclusions 

In this paper, a novel test environment to support in-situ validation of advanced NextGen concepts that rely on future 
air/air or air/ground data exchange is introduced, and a preliminary technical assessment via simulation indicates it is 
feasible. In addition to emulating ADS-B, the NATIVE approach can be applied to other advanced technologies such 
as Controller-Pilot Data Link Communications (CPDLC). Because simulations of these technologies would be used 
rather than the actual systems, NATIVE may provide an additional benefit in enabling evaluation of capabilities that 
rely on proposed message content that does not exist in current standards. Using the NATIVE approach, flight results 
can be used to justify the addition of new message content to future standards. By hosting the ConOp-enabling 
technologies using test equipment rather than certified flight systems, the NATIVE approach may also afford increased 
flexibility and reduced test preparation time. 
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